The Role of Digital Identity in Modernizing Health Care

Mike Engle:
All right, why don't we kick this off? Thanks everybody for attending. My name is Mike Engle. We're here today to talk about the role of digital identity in modernizing healthcare and should run somewhere between 30, 40 minutes. We'll have Q&A inside of our little Zoom chat. Feel free to ask any questions along the way, and we'll do our best to answer questions at the end. This is being recorded, so we'll be able to replay it. You'll be able to come and replay it any time you want to on demand, in case you take an urgent phone call or something like that. I am joined today by two esteemed colleagues, Adam McBride and Ryan Howells. I'm just going to go in that order and ask these two gentlemen to introduce themselves. Adam, could you go first?

Adam McBride:
Of course. Good morning everyone. I am Adam McBride. I'm with HHS. I help facilitate the ICAM Program for HHS. I work for Marsha Levin out of the program support center, and very happy to be here. Thank you.

Mike Engle:
That's great. And Ryan?

Ryan Howells:
Yeah, Ryan Howells. I'm a principal at Levitt Partners and we are a healthcare federal policy consulting firm that was founded by former Secretary of Health and Human Services Mike Levitt, when he left public office about 14 years ago. And one of the unique things we do is we form these alliances to try to solve really difficult issues in healthcare. And if you have healthcare, you know there's a lot of issues. And so we worked on this group called the CARIN Alliance, which we'll talk about. That's one of the initiatives that we help lead. But we're going to talk about some of the work we've done to get individuals more digital access to their data.

Mike Engle:
Awesome. Thank you so much. And Adam is a master beer brewer. I'd love to taste his craft someday. So, maybe we'll have time to talk about that at the end, right?

Adam McBride:
Yeah, we'll have a taste testing.

Mike Engle:
That's right. Virtual. My name is Mike Engle, co-founder and head of strategy here at 1Kosmos, background in InfoSec, but moved into the venture back startup world after my last company, Lehman Brothers, my last big company went bankrupt. And I'm also a general manager in a venture capital fund called 1414 Ventures, which focuses just on identity startups. So, if you've got a great idea or know somebody who started a company, send them my way. So, let's jump in. Maureen is going to, from our marketing team, is going to be asking a couple of questions to the audience. Really simple stuff, kind of yes/no, about how you think about digital identity and health. And this first question, we're just going to jump right in and pop one up if you could, Maureen.

So, very simply, do you have access to your medical information today? And that could be logging into a portal, right? Seeing your appointments, scheduling, those types of things, but really more about your own health data. And I don't think panelists can vote here, but we'll just give this a second. We'll share these results at the end with the recording, and they'll be stitched into the video. So simple yes/no. Why don't we move on from this one, Maureen? A lot of people said yes, 70%, so that's great.

So, just one quick housekeeping. There is a another webinar we're doing next month in January on Passwordless. Can register on our website and we'll be out and about in the industry. If you're in the identity world, come see us at any one of these events. They're listed on our website as well. But the holidays coming up, we don't really get started in these events 'til the first quarter. So, we're here today to talk about the healthcare ecosystem and how data is flowing between them. Specifically, we're going to be talking about the identity components.

And there's a couple of major players in this. There's users, that's me. I need to get service or care and ultimately get access to my data. There's doctors who engage with the users and the hospitals and have their own practice. And then you have payers and providers. Payers pay your bills, the insurance companies, providers give you services. And there's two really simple but pretty hard to solve problems that Ryan and Adam are going to talk about here today is how do I get access to my own medical information? And I'll tell a real world story that I've been wrestling with as recently as 9:00 last night with a doctor. So, I think everybody can relate to this. What records does my physician, my hospital, my specialty care provider, whatever it is, what records do they have, and how do I get access to it?

And then the second one is, how do I share my medical information with others? So, if I go to hospital here, they need to go figure out my medical history. Very simple problem, but hard to solve. There's HIPAA, there's identity, there's connecting the dots between the systems, as well. And that's something that we're going to get into the weeds here on. And as I mentioned, I've been dealing with this very recently. A family member, we'll just call her Grandma for the purpose of this, fell and broke a bone about three weeks ago and it was not pretty. She's had constant care for, she's still not home yet, she's going through rehab. And she had all kinds of workups done. And in that workup, in the first week, they started seeing some anomalies. I think the hemoglobin is normally a nine. It was slowly dropping down to a six.

Now I'm not a doctor, I don't know what that means, but a lot of people were worried about it. And actually my wife is the one that found it on the blood work the hospital did. But now she's getting blood work every day. And we've had a constant challenge getting the doctors to see these because she's been at different providers and getting access ourselves. So, yesterday, we asked for another round of blood work, and again, 9:00 last night, my wife asks me, "What is our fax number?" Why do I have to receive this via a fax? And that's something we're going to be talking about here today. So with that, that was kind of my setting the stage. I'm going to hand it over to Ryan who's going to talk about this very complicated network of entities, and where the CARIN Alliance fits into that and what kind of problems we're starting to solve. And then we'll kick it over to Adam.

Ryan Howells:
Mike, I'm really sorry to hear that about your grandma. That stinks.

Mike Engle:
Yeah. Thank you. She'll be strong, so we'll get through it. Thank you, though.

Ryan Howells:
Yeah, absolutely. And unfortunately, your story is not rare. Fortunately, we kind of fall into two different groups of people, those that stand on stage and say patients don't need access to their data because they're healthy and they haven't had a significant health issue. And those that have chronic conditions or have older people in their family who recognize, caregivers and others, that this is a major problem and it's a big deal that how do you, as me as a patient, since I'm the only constant in healthcare, how do I get more access to my data? It's so important. So, this has been a problem for a while. And as I mentioned, one of the things to understand here is that the US healthcare system actually wasn't digitized. And when I say digitized, meaning literally just on a computer, 85% of it wasn't digitized until five years ago.

So, that's how long it's taken to actually get electronic records in place at scale in healthcare. And then the last five years have been spent trying to figure out how to get the data out of the system so we can have an app economy like really every other industry can have an app economy. And that has been what we have been focused on in the CARIN Alliance. And it's mainly had to do with the policies that have actually been implemented thanks to the enactment of a legislation, a piece of legislation called the 21st Century Cures Act, that was passed at the end of the Obama administration in 2016. There were subsequent regulatory rules that came out, including the one in front of you called the CMS Interoperability and Patient Access Rule. And the one that I'll talk about on the ONC side too, and there's a lot of information on the slide.

The key takeaway on the slide is that for the first time ever, all of the health plans in the United States that are under CMS's regulatory jurisdiction, so that includes Medicaid Fee-For-Service, which is all of the state Medicaid agencies, Medicaid Managed Care, Medicare Advantage, and all of the plans that are actually on the exchanges themselves around the country need to put in place a restful API architecture similar to what we have again in the consumer world along with Open ID Connect and OAuth 2, which are all technologies have been around for a few decades now. Mike and others are super familiar with these technologies. They use them every day, but they don't use them every day in healthcare. And so we've been using antiquated technologies in healthcare for far too long, and now we get to move to more internet-based, modern technologies that is being used by the rest of the country.

All of this infrastructure was put in place in July of last year. So, that is great. And one of the things that were put in place at that point in time is that you can actually select an app of your choice and you can go and download your explanation of benefit information from one of these CMS payers. Unfortunately, commercial health plans were not included on that list, because CMS doesn't have regulatory jurisdiction, but there are some payers that have actually offered that API access on the commercial side too. But it's something absolutely you can ask for now as a result of this rule. So, we'll go to the next slide. The second piece of legislation that came... I'm sorry, the second piece of regulation that came underneath the 21st Century Cures legislation was the ONC Interoperability rule.

The Office of National Coordinator oversees electronic health record technology mainly on the provider side for the country, as a result of some previous legislation that was passed. And so in order for someone to bill Medicare or Medicaid, they'd have to actually implement the standards that the Office of National Coordinator releases. And one of those standards is a core data set for exchanging information using a restful API, they call them a fire API, a Fast Healthcare Interoperability resource. It's based on a standards development organization called HL7 within healthcare. And that core fire API has these following data sets in them, the pieces of data I should say, in them. Which means that as of January 1st of next year, you'll be able to download this information, again using an app of your choice. Two that are free right now is Apple Health. It's actually on your phone, your iOS device, the little heart on your device itself. And then also for Android users, Common Health.

And there's another 31 or so that are out there that are listed on a website called myhealthapplication.com that we help lead where you can access that information through those apps, including clinical notes, which has all of the information that your physician writes about you when you go in and see them. They don't write, actually, they type it into the EHR itself, the electronic health record itself. But you can see that information now both in the portal, as well as in an app of your choice. And so progress is being made. It's certainly not as fast as any of us would like, including those of us who do this every single day. But at least now we have, both on the payer and the provider side, a modern infrastructure that would support restful APIs, Open ID Connect and OAuth 2. Then the question becomes, now how do we actually make this more efficient, more expeditious? What does this look like going forward? So, we'll keep moving forward with this discussion.

Next slide. There is a policy in addition, and along with the Office of National Coordinators Interoperability Regulation that came out called the Trusted Exchange Framework and Common Agreement, or TEFCA. It's a public private sector framework that is going to advance interoperability for the whole country. I won't get into a ton of detail here. What you should know about this in our conversation about identity is that it pointed to the fact that there are guidelines out there, the NIST standards specifically, which I know Mike's going to go into a lot more detail on, and I'll do that here in a second, as well. The NIST guidelines of 863 dash three that are now going to be required under this new common agreement for the country.

The downside is that it's a voluntary agreement. So not every single entity... Unlike the regulation I just mentioned, not every single entity needs to participate in it. The good news is that most entities, if not all entities, are going to voluntarily actually be part of it because it should be a good ramp for how they get more access to that information. So we'll go to the next slide. So how does this all come together? With those two regulatory bodies, as I mentioned, Office National Coordinator and the Centers for Medicare and Medicaid Services, both under the Department of Health and Human Services, of which Adam is a part, has issued these regulations to be able to have a more interoperable ecosystem. There are a number of different standards organizations there in the middle that actually issue these standards. And oftentimes those regulatory agencies at the top point to those standards as being the things that they would like to actually implement moving forward.

And one of those standards is within HL seven, health level seven, which is a standards development organization for data exchange. And they have created this fire standard, which is a restful API standard. You can Google HL seven FHIR, F-H-I-R, and you can learn all about it. We, along with a number of other different entities, have been able to convene the private sector to come together and really tell the standards bodies what we need to have drafted in order to have better electronic data exchange. One of those groups is called the CARIN Alliance, CARINAlliance.com is the name of the website address if you want to learn more about that. The idea here is that we have come together and said, "Let's figure out a way for how individuals can get more access to their data." There's other ones that are out there, too, that are doing more things.

This is a small sampling of the folks that are actually involved in the CARIN Alliance. It gives you an idea including 1Kosmos as a member of CARIN and a number of different big tech companies like Amazon, Google, Apple, and Microsoft. A number of different health plans, some of the largest ones in the country, health systems and individual applications as well, all with a single goal: how do we advance the ability for consumers and their caregivers to easily get, use, and share their digital health information where and how they want to achieve their goals? That is the main goal that we want to try to achieve. We'll go to the next slide.

So in order for that to happen, we need a digital identity ecosystem. So I mentioned the NIST guidelines that was mentioned in TEFCA. That is super important. In fact, they were pointed to that based on a lot of different things. But one in particular is, I know we had recommended that in policy comments back in 2017. And after we did that, we also wrote a white paper, again, it's on our website that you can read. We did that in conjunction with the Open ID Foundation, where we looked at how would we actually create a federated digital identity ecosystem in healthcare? And so we had to go through and describe exactly what that all entailed, and that included in the physical world today, you can get a driver's license. You can produce multiple, what they call trusted identifiers, like your birth certificate, your passport, and other things, to prove that you are who you say you are.

And then you can use that digital identity credential, which is a paper credential for multiple different use cases, whether it's getting on a plane or doing all types of other different use cases related to proving your identity. And we were looking at specifically how you would prove that in the digital world. We'll go to the next slide. And the heart of the paper is the following. One is that we recognize that there was going to be a marketplace of identity providers like 1Kosmos and others that are in that identity provider layer there at the bottom. They would go out and they would be NIST certified. And again, we're going to talk about that here in a second where those NIST guidelines, those individual identity assurance level two and authenticator assurance level two, they would meet those requirements and there would be certifying organizations like the Cantera International Direct Trust that certifies organizations and certifies technologies that are both PKI specific and API specific.

But we also recognize that for us to have a fully interoperable ecosystem, it requires an ability for us to actually develop standardized policies by which we could have interoperable trust frameworks. What does that mean? It means that there are NIST guidelines and there's also RFCs that are out there. NIST 853, 863 and then RFC 3647, which is the X509 certificate standard. Those three things actually needed to come together in a common way. For example, the definition of a certificate or the definition of a credential where they're really the same thing. It's just what are we going to call it, and when does it expire, and can we have some consistency across the board? We've spent two years on this project, and we are at the end of that work. And as a result of that, we're going to have a policy equivalency across these different trust framework organizations and standards, which will allow for a relying party to trust the identity provider no matter what technologies that they use, either PKI or API specific.

We're really excited about that. It will be an open framework that anyone can use. And we've been working with the federal government on how that looks. In addition, we're looking at specific workflows in a pilot because we said, "We should test this," and it makes sense to actually figure out a way to test this. And we decided to test it in three different workflows. And we have about 30 organizations testing this as well, including Adam's group. One is a credentialing service provider standalone. Can an individual actually access that data from one of these credentialing service providers that have been certified? Second one is, could we use an identity broker service that Adam's going to describe called the HHS XMS system that's live and in production. And the third area was could we use an open standard called UDAP tiered OAuth so that two organizations, a credentialing service provider and a relying party, could actually connect to one another, even if they didn't have an existing relationship. And there's a standard by which, an open standard called UDAP that actually makes that happen.

I think the last slide here, this is my last slide and I'll turn over to Adam, but we have a ton of really great participants including 1Kosmos in this proof of concept that are basically saying, "Let's test those different workflows. Let's test multiple relying parties, multiple CSPs including the federal government, Office National Coordinator, CMS, as we mentioned, Adam with HHS and others are all participating in this to see how in a public-private sector way in the United States, how could we figure out opportunities where someone could prove their identity once, get a digital identity credential, and use it multiple times across multiple relying parties. And we're finding great success and plan to write up our findings early next year, and it'll be published on our website so that everyone can learn from that and hopefully adopt a lot of the things that we've been able to learn. So with that, I'll turn it over to Adam.

Mike Engle:
Yeah, we're going to pop up one quick second polling question. It's as easy as the last one and a little more granular. So 70% of our participants said they do access their stuff online. How many have downloaded it into an actual wallet where then you can take it with you, look at it offline, right? So a lot of people don't even know what you said about Apple Wallet and I was surprised how far back that went to iOS 11, four or five years ago, when they first rolled that out. Okay, thank you for that, Maureen. And with that, I'm going to hand it over to Adam, talk about XMS.

Adam McBride:
All right, thank you, Mike. Thank you, Ryan. Ryan basically stated a lot with what we're doing with the CARIN Alliance. What I'm going to do real quick is to briefly go over what XMS is. So you probably got a good idea just from what Ryan was explaining, is that basically we're a federated identity broker for HHS, but we're also doing it for the CARIN Alliance proof of concept. So we have a platform to where we can bring in credential service providers such as 1Kosmos, id.me, login.gov, and we're able to provide the HHS agencies right now the means to allow the external user to have the authentication needs to get into the application for HHS. So currently, we can provide IAL1, AAL2, IAL2, AAL2 capabilities along as well as the PIV CAC card authentication.

So with that, the CSPs that we do bring into the XMS platform, we make sure that they are all NIST compliant. As Ryan stated earlier in the slides, we do leverage the third party assessors like the Cantera initiative and Direct Trust folks to make sure that they are NIST compliant. We take then give the possible credential service providers who want to come onto our platform, we give them our evaluation document, they fill that out and we look at it and they have to meet all the requirements that we have for the needs just to be on our network and to go through our proof of concept. We do the proof of concept in our lower tier and we fully vet out the credential service provider. That usually takes, I believe, roughly three months. Is that what it took for you, Mike? Three months?

Mike Engle:
Yeah, that sounds about right.

Adam McBride:
When you're done, we do a complete write-up and we let the credential service provider know how they did on the proof of concept. And from there, if we have the use case and the need, we will pursue the procurement to bring them aboard. I really won't go over this slide that you see right now. Hopefully you are reading it. I'm sorry, one second. Thing with doing this at home, you get dogs barking in the background. My apology. Give me one second.

Mike Engle:
Yeah, I get five Amazon deliveries a day sometimes, and it's constant entertainment.

Ryan Howells:
We keep the Amazon delivery truck in business, Mike, in my house too.

Adam McBride:
It's always the little dogs that are the worst, right? My apologies. So let's see, where was I? So with the XMS, to give you a highlighted view of the workflow. So the application that is integrated with XMS, basically you'd go to their website and you click the login or sign in button, whatever they have. From there, the agency application has the opportunity to either go to our landing page to where the user will see what you see on the right hand side of the slide, whether it be login.gov, id.me, 1Kosmos, or like I stated before, PIV CAC. And we do actually have starting tomorrow FIDO capability, which will be another button underneath the PIV CAC, but they'll select the means that they want to use for authentication. So we have applications only needing IAL1, AAL2, they would use login.gov. For IAL2, it would be id.me and 1Kosmos.

So the user, if they have an account with one of these entities, they would just select the button and go ahead and log in. The agency does have the choice of doing what we call the auto forward to where if the user selects the login button or sign in button, it will go to the agency's credential service provider of choice. So it could go straight into 1Kosmos, id.me, or straight to login.gov.

With that, if there's an application that requires an IAL2 and the individual previously signed in and they were only at an IAL1, they would step up. And I believe Mike's actually going to show that later in the presentation. Oh, one more thing. On the bottom there, there's a link. If you want to see what our landing page looks like as we move along, you can go to that link. And here's a quick breakdown on the XMS architecture, just to give you a quick highlight of how we're set up. As you can see, open ID and SAML is usually what we use. And yeah, most of you probably know what all this is, so I'm not going to explain it. I know I'm short on time.

Mike Engle:
Yeah, no, I think...

Adam McBride:
That's it.

Mike Engle:
Really helpful, Adam. Thanks, and I'm going to break down the actual implementation that we did together with Adam and his team in just a minute here. When we talk about, for those that don't know IAL1, IAL2, it's really simple. IAL1 is just self-assertion on the internet for the most part. It means you're a name. You go to macys.com, you create an IAL1 account, it gets strengthened. You provide a credit card or you may have to provide some other information, but it doesn't have a super high standard, and that's what NIST 800-63-33 does. So I helped my dad sign into Social Security and Medicare about a year ago, and I happened to take screenshots because it's what I do so I could tell a story like this, and this is the process he went through. We went through login.gov.

I had to get an authenticator app, which no way in any planet that my dad could do. So I now have his second factor on my phone, and then he had to verify his identity. So this is all manually typed in data, and then verifying the driver's license number actually failed in this example. I don't know why, if I constantly typo'ed his driver's license, but it failed. And then we had to put in a valid credit card. You can see where this could be painful for the user and easily, really frankly, very easily accessible for a bad actor. This data has been stolen so many times from the bureaus that it's almost useless. You can buy it for pennies on the dark web. So there's a better way, and that's one of the reasons that NIST 800-63-3 came out to say, let's verify this stuff and triangulate some data.

So the NIST 800-63-3 standard has two components, identity assurance level IAL, and authentication assurance, AAL. And the IAL side helps you establish identity. It typically requires two, what they call strong forms of documentation or verification or one superior, et cetera. And then your face needs to match the credential. So as you can see, it's already much stronger than just typing in some data that the bad guys already have. And then on the authentication side, Ryan mentioned FIDO. Adam mentioned FIDO, super exciting. It's the Passwordless standard that's been around since 2013. It allows you to use a key on your device and a biometric to get into a system. And so you put these together, it's really starting to bring identity to places that didn't exist before. And also mentioned from Ryan and Adam, where some of these certifying organizations, nonprofit, Cantera, Direct Trust, the FIDO Alliance certifies their products as well.

We are certified for both of these and also certified for iBeta biometrics. So it's important to know that the entity you're working with is certified. And so the couple things I'm going to show you next is modern identity proofing and verification in a single experience for a user. We're going to leverage the camera that's on billions of devices today. We're going to put a key on that device as well. And then we're going to verify the data with the issuing authorities. So that's AMVA for driver's licenses, it could be the Department of State Public Certificates for the passport data, et cetera. And if you do this right, you could have a credential that doesn't involve a password. You're always going to have a password, well, not always, but you need fallbacks. So we'll have them around for some time, but the future is near for getting rid of passwords, especially with things like FIDO pass key.

So I'm going to walk through what it looks like to do an XMS integration, IAL2. But first I wanted to show one of the websites that integrates with Adam's systems today. This is called HRSA. And this is, I just recorded this morning, just so you could get a feel for what it would look like to go sign up for a service using today, call it the before. So you'll see clicking this button, saying I would like to log in and I don't have an account. So you have to go create an account, right? Then pops in today, interfacing through login.gov is Adam's XMS system, going to his HHS XMS system. And this is where now we have a pilot showing you the new way that it could be done, which is what's coming next. Did I tee that up upright, Adam?

Adam McBride:
Yes. And this is for the IAL1, AAL2 as well.

Mike Engle:
Right. Yeah. So this is one of the existing IAL1 systems that are out there. So let's step through what we've put together. We are going to go, this is that same screen that Adam was showing just a minute ago. And we're going to step through an identity proofing exercise that just takes a couple of minutes, but yet has a very high level of trust and reusability across different agencies. That's what's going to be most exciting about it. So you'll come to a very similar screen. Let's create an account, get started, and it'll go through your traditional, I need your email, all right, fine. Click a link, verify you have an email address. Now we know how to get ahold of you. That's how you'll log in. And then let's verify. Just we ask for first name, last name, and we need to verify a phone number as well.

For a couple reasons. We may need to use it for fallback authentication. We may need to get ahold of you. We have a pretty clever mechanism to verify a phone number by simply taking your phone out and scanning a QR code. That generates a quick text message. Press send, and your phone number is verified. Takes about two or three seconds. So there's other ways to do it, right? If you get sent a code, go get the code, go type it into a webpage, but we've basically set up an IAL1 account. We're ready now to strengthen it and get it up to IAL2. So it's there and it's ready. And your identity is just waiting to be verified. Now, at any point in the process, we could implement passwordless. So this button in the middle would be your device biometrics, touch ID, face ID, Windows Hello, et cetera.

And that could pop up and that could then be your strong authenticator going forward. We're not going to get into that on this call. I've got 12 other webinars that cover passwordless. If you want to see any of those, just hop on the website and check them out. We'll skip that for now.

And so we created that IAL1 and we came now to an HHS landing page. It's not been verified. So we need to verify our identity before we can consume certain types of services, right? Before you'll give me social security benefits, this identity has to be verified, or before I go into my Aetna account, right? That's the idea that we're building here. So we're going to click this button to link or create a 1Kosmos wallet here. And the term wallet is really important. So this is the genesis of a wallet. It involves some type of thing that's in my control. In this case, we create an encryption key, an eight digit pin, and then now everything we do going forward will be encrypted with that. So we're going to enroll driver's license by simply routing the session over to the smartphone and having the user snap a couple photos with their camera. We'll do that next.

So I received the text message and I just follow the prompts on the screen. Take a picture of the front of the license, take a picture of the back, right? The user is guided through this because you're dealing with a very large population that might not get it, give them a couple tries, maybe. But you can see it's pretty straightforward. It's auto capturing, it's guiding the user on how to hold the phone, did the front, did the back. Now we take the live selfie, which matches the user's face to the face on the government credential, and we just onboarded a government document into a digital wallet. Now, we also support passports, and there's all kinds of other documents that are supported in this flow. Lastly, we need to get a social security number. In this example, there's other ways to go about this, but the reason for that is to match the driver's license to the address of record for you.

So when I have mine done, I have 31 addresses on file and luckily one of them matches my driver's license. And it's a way to verify that this is who they say they are, gets you now. That is an IAL2 identity onboarding, right? Much easier and much more trusted than the old way that I showed on the prior screens. Now we are prompted to share the data out of my wallet into the XMS system. So this prompt would pop up and say, "All right, I've got your data in your wallet now. Are you willing to share it with this requesting party?"

And at this point, the data is unlocked and transmitted via those identity protocols that Adam mentioned, and my account is strongly linked to a verified identity. And then when I come back to my profile page, you'll see that you are now in the system with a verified IAL2 identity. So very straightforward, but hard to do in practice because there's just so many variables. And then the next step in that, that the CARIN Alliance is working on is to have that identity be reusable across payers, providers. And there might be a different way that Ryan or Adam wants to tee that one up.

Adam McBride:
Can I highlight something there, Mike?

Mike Engle:
Please.

Adam McBride:
Just so everyone's aware, for the actual IAL2 step up, I would say 95% of the time what you see on what you're capturing, Mike, I'm glad you captured this, because this is actually what the XMS user site looks like, if they go into XMS. 95% of the time, the users will not even see this, because it'll be automatic. So if a user has to step up, it'll be done automatically. They won't have to go through a bunch of these pages. So it all depends on the application that they're linked to. And then also, just so everybody's aware that once the individual... What you basically see on that page right now is all the information that XMS stores except for the IAL level and AAL level. So the social security, the driver's license, all those certain attributes, we pass those through to the agencies that need it.

And for each application that's integrated with XMS, they identify what attributes they want. Then when the user signs in through 1Kosmos, at that time, those attributes go through XMS to the agency for the application so they can properly identify and make sure that they're permitted to gain access into the application. We don't store any of that information on our system, so that's why we leverage the credential service providers, is that you maintain that, and then we just basically facilitate the authentication identity proofing levels. And going back to with the CARIN Alliance, the reason that this is important, so we have multiple credential service providers. So users could use any credential service provider that they want that's integrated with our platform and log in to any of the integrated relying parties, like any healthcare agency patient data center. So they would be able to use the XMS system where they could log in once and use that particular username and authentication to go into those integrated applications. So that's where we would help out in this instance.

Mike Engle:
No, it's really helpful.

Adam McBride:
Sorry.

Mike Engle:
No, that's great. You live and breathe this every day. So that context is really helpful. Is it similar, Adam, to what login with Google would be like today? So if you have a user over here on the left and they're trying to get to a hospital over here or whatever it would be, some type of provider that they would have a button here and that would route over to XMS. It does its thing. Verifies what level of identity comes back and then they're in, without actually really having to see this landing.

Adam McBride:
Exactly. And we can help facilitate the IAL2. We maintain that within our system. So the individual will not have re-identity proof every time. So they only have the identity proof that one time. And we maintain that. Once they're at that level, they can use that authentication and identity proofing for that session.

Mike Engle:
And if the password list was enabled in that session, they won't need passwords into all those RPs, right?

Adam McBride:
Exactly. Yes, it's the user's choice, right?

Mike Engle:
It's going to be glorious.

Ryan Howells:
And that's where I come in, Mike, is the stuff that we're doing in CARIN is going to allow all of these policies and the security protocols and all those things to actually just work seamlessly. So that, for example, if HHS XMS gets uploaded on every portal in the entire country and Healthcare Portal, and then every app, let's say hypothetically, there's an ability for that to happen. But in addition to that, even if it's not uploaded, there's an opportunity for 1Kosmos to take advantage of what we're doing as well as other credentialing service providers that essentially if you do this once, you don't have to do it multiple times. That's kind of the intent. And it is intentionally a little bit of a friction full process. But the idea is, I don't want to do it again, I just want to use my 1Kosmos ID across multiple different entities. And that's the same principle that we're looking at in healthcare. I should use it on my payer, my provider, my third party app of my choice, whatever I want to do to make sure I can get access to my health information.

Mike Engle:
That's great. I've been watching the global identity networks for a couple years. Banking in some countries, in Singapore, South Korea, and this is the first one in the United States I've seen that really is this far along and has so much promise, especially in such a needed space. So thanks for all your hard work, guys. One third question here. Now that you've seen this, and heard Adam and Ryan describing the art of the possible, and what's coming in the future, would you buy into that? Hopefully this is a hundred percent yes, but I'm sure some of you will be like, "Eh, no, it doesn't feel right, whatever but just very simple yes/no. So if you could pop this one up, Maureen, we'll take one more quick pulse from the audience here.

I can't wait for this to happen. So you can hit yes a couple times for me, Maureen. That'll be great. And with that, we're calling it a wrap. There was a couple of questions that came up. I just want to, all right, we're at 96% yeses. All right, so we had one naysayer, a couple of naysayers in the group. That's okay, we'll win them over, right, guys?

So one of the questions I saw pop up, it was probably already answered, I'm not sure if everybody can see them, but what if your passport data is eight years old? You have to get them every 10 years and the picture doesn't match. And yeah, there will be exceptions. This is not 100% just like, you try logging into some systems, you just can't get in, you have to call somebody. It's just the nature of the beast. But the goal is to get a majority in. If we can serve 80% of the population with this modern, more secure way, is taking a huge amount of friction off of the providers and off of the identity providers as well. So there's multiple types of documents you can use. There's other ways to handle that. And then you could always fall back to manual verification. So that's one of the...

Ryan Howells:
Yeah, I'd just add to that, Mike, right now we have a 0% solution in how you reuse an identity, right? So we want to increase that percentage up and whatever number we get to, 50, 60, 70%. The question that the person was asking had to do with minor identity. And honestly, to be quite frank, there really isn't anybody that I know of, at least, that have actually figured out the minor identity issue yet.

And the reason for that is because you have all kinds of situations. You have what's called unaccompanied minors. You have folks that are, for example, on Medicaid, 50% of all the people that are on Medicaid right now all over the country are minors. And so it is a problem we need to solve for sure, but you got to figure out a way to identify who is the custodian of the minor themselves, and then how do you link that custodian to the minor. And that's a bigger issue than just, it's a legal issue, it's a contractual issue, it's a custody issue. There's all kinds of other things related to it. So it's hard sometimes to actually do that with minors. This is primarily, I know, on the adult side itself, and like I said, let's get this working for a higher percentage of zero and then work on some of those other use cases.

Mike Engle:
Yeah, actually one of the exercises I went through as part this was trying to download more and more of my Apple Health data as I was preparing for this webinar. So it was really cool for me to do it. But I got into one of my Hackensack Hospital here and that was cool. I saw all my charts and when I put in my Quest username and password, all my son's blood work came into my wallet. All right, so that's an example. Because I signed up for his account, so I put his social in, I probably used my birthdate or something. So there's challenges and devils in the details for this stuff for sure. One other question was, what happens if 1Kosmos, the CSPs get breached? And that is a big deal. What if the DMV gets breached and all of your driver's license data is out there now?

We address that a very specific way. We don't have access to any of the data. That wallet concept that I described puts the user in control and we use really distributed ledger technology to make sure it's only in the user's control. So if I put my propeller hat on and went and tried to get into the system and tried to find your identity information, I do not have access to it. That's what keeps the GDPR certified. And there's other providers that are doing that stuff as well. So it's another important design consideration that could be an overall aspect of the solution.

Adam McBride:
And can I add to that, Mike?

Mike Engle:
Please, yeah.

Adam McBride:
Just so everyone's aware that's one of the benefits of having a federated portal like XMS to provide identity. So God forbid anything would happen to 1Kosmos, or id.me, login, what have you. If you're integrated with a federated platform, if something would happen, you can shift to another credential service provider. They would have to re-identify through the other credential service provider. However, it alleviates the risk of any breach at that time. So if there is an issue and the agencies do want to change, they can do that. But say 1Kosmos went away one day, we have others to fall back on. So I just wanted to add that real quick.

Mike Engle:
Yeah, no, that's a great point. And with that, Ryan or Adam, any final thoughts before we pop up our final poll?

Ryan Howells:
Just last thing I'll say, Mike, is that all the things we're doing in the CARIN Alliance is open to everyone. So keep track of us on Twitter, keep track of us on the website. The work we're doing with 1Kosmos and other CSPs and other relying parties out there is going to benefit not just US healthcare, it's going to, as Mike mentioned, it's going to benefit all types of different sectors. These standards are not sector specific, they're across standards. They're functional in the sense that they're related to identity and authentication. And so if we can get this right in a distributed US healthcare environment, then there's hope for other sectors as well, whether they're distributed or centralized. And that helps us a lot in terms of reusable identity credentials that could be harnessed for all kinds of different purposes. So we're really excited to tell the world more about what we learned over the course of this proof of concept in the last year.

Mike Engle:
And maybe you can tackle open banking next, Ryan. That would be awesome.

Ryan Howells:
Well, it's funny, health care's behind everybody, Mike, but in this specific instance, we're ahead of banking.

Mike Engle:
Exactly.

Ryan Howells:
So we're super excited about that.

Mike Engle:
Well that's great. So listen, with that, I am putting on my holiday jacket here, getting ready for things to slow down, and what do you think? You like it?

Ryan Howells:
That's excellent. That looks like a Christmas party. Where's my ugly sweater, too?

Adam McBride:
I know, I was just getting ready to say that. I'll throw mine on real quick. I'm sure everybody will love it.

Mike Engle:
I couldn't wear it for the whole webinar. It would've been too distracting for me. But final polling question, Maureen, this is just for Adam really, but it is during the holidays. What is your...

Adam McBride:
Well, that's an easy question. What's Yuengling on there?

Mike Engle:
No.

Adam McBride:
Oh, man.

Mike Engle:
There's only one right answer.

Adam McBride:
What? My home brew.

Mike Engle:
That's right.

Adam McBride:
My goodness.

Mike Engle:
That's right. So no pressure, but you better get that stuff cranking. So no, just for fun. Thanks everybody. It was great chatting with you, Adam and Ryan, appreciate your time on this and super excited to be a part of the CARIN Alliance.

Ryan Howells:
We're excited to have you. Thanks everybody. Appreciate this.

Adam McBride:
Thank you. Take care. Happy holidays.

Ryan Howells:
Bye-bye.

Adam McBride:
Bye.